KubernetesInformerCreatorTest.informerInjection fails on Windows because both the pod and configmap watch stubs shared a single watchCount semaphore. On Windows, the pod informer can complete LIST→WATCH, receive the empty {} response, and immediately loop back to fire a second WATCH — all before the configmap informer makes its first WATCH request. Two pod-watch firings then satisfy watchCount.acquire(2), letting the test advance to verify() before the configmap watch ever happens.

Changes

• Per-stub CountDownLatch(1) instead of shared Semaphore: replaced getCount/watchCount (shared across both informers) with four independent latches — podGetLatch, podWatchLatch, configMapGetLatch, configMapWatchLatch — each wired to its own stub
• Idempotent signaling: CountDownLatch.countDown() is a no-op once at zero, so repeated firings from one informer cannot accidentally satisfy another informer's gate
• Updated CountRequestAction: switched from Semaphore.release() to CountDownLatch.countDown()
• List-before-watch ordering enforcement: each watch stub carries the corresponding get latch as a "prerequisite" parameter; CountRequestAction.doAction records an AssertionError in a static AtomicReference<Throwable> orderingViolation if a WATCH fires before the LIST has completed, and the test asserts that field is null at the end

// Before: shared semaphores — pod watch firing twice satisfies watchCount.acquire(2)
Semaphore watchCount = new Semaphore(2);
watchParams.put("semaphore", watchCount); // same params for BOTH pod and configmap stubs

// After: independent latches with ordering enforcement
CountDownLatch podGetLatch = new CountDownLatch(1);
CountDownLatch podWatchLatch = new CountDownLatch(1);
podWatchParams.put("semaphore", podWatchLatch);
podWatchParams.put("prerequisite", podGetLatch); // enforces list happens before watch
// ...
podGetLatch.await();
podWatchLatch.await();
assertThat(orderingViolation.get()).isNull();

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.